Software products (apps) are made up of thousands (and sometimes millions) of parts. The “parts” in a software product are generally lines of code. Like lines of words in a book, lines of code are lines of instructions for a computer. For example, line one might say “add 1+2”, line two might say “multiply 3×4”, etc.
Testing software is complex because a software product is generally made up of so many lines of code. To reduce complexity, the testing of the entire app is broken down into much smaller individual tests. For example, in a calculator app, there would be individual tests for addition, subtraction, multiplication, etc.
Knowing the association between lines of code and tests in a software app is valuable. It enables simplifying testing, if parts of the software application are changed, without requiring retesting of the entire application. So knowing the association between parts and tests can save a company a lot of time. And time is money.
In the prior art, in order for software testing systems to record an association between a test and the associated line(s) of code, the software application has to be stopped after each test.
But there is a problem. Starting and stopping the software application for each test is time consuming. It would be a lot faster (and cheaper) to start the software application once, perform all the tests and then stop the application. However, the instrumentation, in the prior art, only permits recording the test when the software application is stopped.
As long as a software app is started and stopped for each test, the recorded lines of code can easily be associated with each test. However, in the prior art, there is no way to start the software app once, perform multiple tests, and have the recorded lines of code associated with the correct individual tests.
Because many software apps take *minutes* to start up. Starting and stopping the software app for hundreds and thousands of individual tests is simply not practical.